1. Field of the Invention
This invention relates generally to Universal Serial Bus (USB) interfaces and Secure Digital (SD) device interfaces, and more particularly to the design of a USB-to-SD bridge.
2. Description of the Related Art
The Universal Serial Bus (USB) was developed to offer PC users an enhanced and easy-to-use interface for connecting an incredibly diverse range of peripherals to their computers. The development of the USB was initially driven by considerations for laptop computers, which greatly benefit from a small profile peripheral connector. Among the many benefits of the USB is a reduction in the proliferation of cables that can affect even the smallest computer installations. In general, USB has become the interface of choice for PCs because it offers users simple connectivity. USB eliminates the need to have different connectors for printers, keyboards, mice, and other peripherals, and supports a wide variety of data types, from slow mouse inputs to digitized audio and compressed video. In addition, USB devices are hot pluggable, i.e. they can be connected to or disconnected from a PC without requiring the PC to be powered off.
The USB specification has seen various revisions, with the USB 2.0 standard challenging the IEEE 1394 interface (“Firewire”) as the interface of choice for high-speed digital video, among others. With the proliferating design of increasingly smarter, faster, and smaller peripherals, the On-The-Go (OTG) Supplement to the USB 2.0 Specification was developed to address the growing popularity of the portable electronic devices market. Some of the advantages of the USB and OTG include the built-in support in more than 1.4 billion USB enabled PCs and peripherals shipped worldwide, smooth and trouble-free experience for the user through a compliance and logo program operated by the USB-IF, a wide variety of USB solutions such as intellectual property (IP) blocks, system-on-chip (SOC) parts, discrete chips, software drivers and systems offered by a large group of industry vendors, and design flexibility based on system needs.
OTG devices typically do not require a PC host, and can communicate directly with each other. For example, a PDA may act as a USB host with the capability to print directly to a USB printer, while also acting as a USB peripheral to communicate with a PC. In general, designers are facing increasing pressure to design smaller and faster products in less time and at lower cost. Concurrently, the introduction of smaller deep sub-micron processes present new challenges, such as integrating the physical layer (PHY-transceiver) analog circuitry required by technologies such as USB and OTG, leading to increased man-hours, fiscal and time investment, and silicon revisions. One way to increase time-to-market while keeping costs low is to provide the PHY in a separate chip. In such a case the designer can typically integrate most of the USB digital logic into the application specific integrated circuit (ASIC) in a small amount of time, and connect to a proven external PHY already available on the market.
Following the release of the USB 2.0 specification, Intel released the USB 2.0 Transceiver Macrocell Interface (UTMI) specification. UTMI defined an interface between two IP blocks, the USB Transceiver Macrocell (IP) and the USB Link layer (SIE). For example, the UTMI can be used to interface between a USB Link and a USB PHY. The signals for a UTMI interface with an 8-bit bi-directional data bus. Typically a minimum of 22 signals is required between the Link and the PHY for a device.
Subsequently, an extension of the original UTMI specification the UTMI+ specification was developed to meet the emerging need of building embedded host and OTG capabilities into USB devices. While the original UTMI specified an interface not meant to couple discrete ICs, the UTMI+ in essence introduced host and On-The-Go capabilities to USB systems. Using UTMI as a starting point, UTMI+ incrementally adds new functionality and interface signals to the Link and PHY. The additional signals total 33 for a full OTG UTMI+ interface. Designers can reuse all blocks from their original UTMI IP, and need only add the new circuits required for host or OTG support. This approach works well for UTMI+, as USB peripherals need only a subset of host and OTG functionality. UTMI+ introduced four levels of functionality, each higher level increasing the complexity required in both hardware and software while remaining completely backward compatible with lower levels.
A Low Pin Interface (LPI) UTMI+ specification, referred to as ULPI, was developed by USB industry leaders in order to provide low-cost USB and OTG PHYs by way of a low-pin, low-cost, small form-factor transceiver interface that may be used by any USB application. Pre-existing specifications, including UTMI and UTMI+ were developed primarily for Macrocell development, and were thus not optimized for use as an external PHY. Building upon the existing UTMI+ specification, the ULPI reduces the number of interface signals to 12 pins, with an optional implementation of 8 pins. As a result, the package size of PHY and Link IC's has generally been reduced, not only lowering the cost of Link and PHY IC's, but also reducing the required size of the associated printed circuit boards (PCBs). Central to the ULPI specification is the LPI, which is in effect a generic bus that defines a clock, three control signals, a bi-directional data bus, and bus arbitration. Typically, a ULPI link will configure the ULPI PHY using register writes on a bi-directional shared data bus. The ULPI PHY is the arbitrator of the 8-bit data bus between the link and the PHY.
Secure Digital (SD) is a non-volatile memory card format widely used in many portable devices such as digital cameras, digital camcorders, handheld computers, laptop computers, personal digital assistants (PDAs), various media players and mobile phones, as well as video game consoles and GPS receivers. The format has gained widespread popularity. Although most SD-cards have the same physical shape and form factor, the respective interfaces of more recent high-capacity (SDHC) cards and extended capacity (SDXC) cards have been modified with respect to the interface of the established format, making some older devices designed for standard SD cards unable to accept and use SDHC and SDXC cards. There are currently three versions of the SD specification: 1.0, 1.1 and 2.0. A simplified version of the host controller interface specification for SD cards (different from the physical specification, which covers the actual cards and their protocol) was released in 2006, and at least Linux drivers for SD cards are now widely available.
In most desktop systems, SD cards are generally read via USB-based card readers. These card readers present a standard USB mass storage interface to memory cards, thereby separating the operating system from the details of the underlying SD interface. However, embedded systems (e.g. portable media players and some cellular phones) typically have direct access to SD cards, which generally requires complete programming information. Desktop card readers can themselves be considered examples of embedded systems for which complete access to the SD specifications may be necessary. Many notebook computers now include SD card readers not based on USB device drivers, essentially accessing the SD card directly in a manner similar to SD card access in embedded systems.
SD supports at least three transfer modes. A 1-bit SD mode using separate command and data channels and a proprietary transfer format, a 4-bit SD mode using extra pins and some reassigned pins, and a serial mode using a Serial Peripheral Interface (SPI) Bus that features a simpler subset of the SD protocol for use with microcontrollers. All cards must support all three modes, except for microSD, for which the serial mode is optional. The cards must also support clock frequencies of up to 25 MHz for regular cards, and 50 MHz for high-speed cards. In addition, a combination of SD card and I/O device, referred to as Secure Digital Input Output (SDIO) device, has found increased use in portable electronics devices, such as PDAs, laptops or mobile phones. SDIO cards are fully compatible with the SD Memory Card host controller (including mechanical, electrical, power, signaling and software). SDIO requires support of an SPI bus topology and supports most standard SD commands.
At the present time, many microcontrollers do not support an SD interface, while they may have built-in USB ports. Systems using SDIO typically have custom device drivers that send SD/SDIO commands directly to an SD standard host controller. Various USB-based solutions typically employ custom device drivers not modeled around industry standards, and as a result, require significant rework to existing SDIO drivers to allow a particular SDIO device to be used. There are no known generic USB-to-SDIO implementations that seek to transport generic SD/SDIO commands and data over USB. Additionally, there are no known implementations that attempt to optimize the SD/SDIO command flow for performance. Another group of solutions (referred to as “Direct Connect with SPI”) feature a direct connection from SDIO devices to the microcontroller using SD/SDIO in 1-bit mode, employing an SPI host controller to transport data. These implementations typically require custom, and oftentimes single-device-specific driver stacks. Finally, some solutions (referred to as “Direct Connect with Bit-banging”) connect SDIO devices directly to the microcontroller using SD/SDIO in 1-bit mode while manipulating GPIO (General Purpose I/O) pins directly with firmware, also requiring custom, and oftentimes single-device-specific driver stacks.
The above solutions suffer from performance limitations, however. For example, both direct connect methods (Direct Connect with SPI and Direct Connect with Banging) suffer serious performance issues due to the SD bus operating in 1-bit mode, and the relatively low speed of the bus when bit-banged. USB-based solutions potentially suffer from performance issues due to host side latency and lack of command/data flow optimization of multiple small transactions. There may also be host-side driver complexity issues. The implementations mentioned above all suffer from lack of standardization, which typically results in significant driver development for each SDIO device on every platform where the bridge/connection mechanism is to be used.
Other corresponding issues related to the prior art will become apparent to one skilled in the art after comparing such prior art with the present invention as described herein.